Most GNU packages run on a wide range of platforms. These platforms are not equally important. The most important platforms for a GNU package to support are the free variants of the GNU operating system, regardless of which kernel it uses.
The GNU Project’s practical work is developing the GNU operating system; a GNU package should make the whole GNU system more powerful and encourage people to switch to that system.
Please keep those goals in mind in your work. For instance, every new feature you add should work on GNU. If a new feature runs only on GNU (for instance, on GNU/Linux), it is acceptable. However, a feature that runs only on other systems, and not on GNU, would undermine the goal.
Therefore, please say no when asked to implement such a feature, citing these reasons, and ask the contributors to implement the feature for the GNU system as well. See Patches Not to Accept.
You will naturally want to keep the program running on all the platforms it supports. But you personally will not have access to most of these platforms—so how should you handle them?
Don’t worry about trying to get access to all of these platforms. Even if you did have access to all of them, it would be inefficient for you to test the program on each platform yourself. Instead, you should test the program on a few platforms, including some free variants of GNU, and let the users test it on the other platforms. You can do this through a pretest phase before the real release; when there is no reason to expect problems, especially in a package that is mostly portable, you can just make a release and let the users tell you if anything unportable was introduced.
It is important to test the program personally on GNU or GNU/Linux, because these are the most important platforms for a GNU package. If you don’t have access to one of these platforms, as a GNU maintainer you can get access to the general GNU login machine; see https://www.gnu.org/software/README.accounts.html.
Supporting other platforms is optional—we do it when that seems like a good idea, but we don’t consider it obligatory. If the users don’t take care of a certain platform, you may have to desupport it unless and until users come forward to help. Conversely, if a user offers changes to support an additional platform, you will probably want to install them, but you don’t have to. If you feel the changes are complex and ugly, if you think that they will increase the burden of future maintenance, you can and should reject them. This includes both free or mainly-free platforms such as OpenBSD, FreeBSD, and NetBSD, and nonfree platforms such as Windows.